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[57] ABSTRACT 

A distributed redundant database architecture (10) primarily 
for storing a plurality of wireless service subscriber files (84, 
86) is provided. The database architecture (10) include a first 
set of processors (44 46, 48) each having a shared memory 
(72, 74, 76), where the processors (44, 46, 48) are divided 
into processor groups (38, 40, 42). A memory storage device 
(80, 82) is coupled to each processor group (38, 40, 42) in 
a multi-initiator mode so that each memory storage device 
(80, 82) is accessible by the processors (44, 46, 48) in its 
respective processor group (38, 40, 42). The plurality of 
subscriber files (84, 86) are assigned to the processor groups 
(38, 40, 42) and further assigned to the processors (44, 46, 
48) in each processor group (38, 40, 42) to achieve a 
substantially even distribution. The plurality of subscriber 
files are stored in the memory storage devices (80, 82) of 
respective assigned processor groups (38, 40, 42), and are 
mapped into the respective shared memories (72, 74, 76) of 
the processors. A database manager (52, 54, 66) associated 
with the processors and processor groups is provided for 
managing the distribution and redistribution of the sub- 
scriber files to the processors. A second set of similarly 
configured processors residing at a remote site (14) main- 
tains a second copy of the subscriber files (84, 86) to provide 
database backup. 

49 Claims, 10 Drawing Sheets 
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DISTRIBUTED REDUNDANT DATABASE 
RELATED PATENT APPLICATION 

This patent application is related to a co-pending U.S. 
patent application, Sen No. 08/526,953, titled System and 5 
Method for Multi-Site Distributed Object Management 
Environment. 

TECHNICAL FIELD OF THE INVENTION 

This invention is related in general to the field of tele- 1C 
communica lions equipment. More particularly, the inven- 
tion is related to a distributed redundant database system for 
a wireless communications network. 

BACKGROUND OF THE INVENTION 15 

In a wireless communications network, voluminous infor- 
mation is maintained about subscribers* wireless service 
subscription, such as service options, preference 
information, billing information, and current location. All of 
this information is stored and maintained in a subscriber 20 
database. In a system supporting tens of millions of wireless 
service subscribers, the subscriber database attains a very 
considerable size. 

Coupled to the size requirement of the database is a speed 
requirement. The information related to each of the tens of 25 
millions of subscribers must be readily accessible, as soon as 
a subscriber turns on the personal handset to make a tele- 
phone call. Further, because of the substantial number of 
subscribers, the number of database queries and updates can 
become unmanageable if the database is not properly 
designed and configured. 

In addition, it is desirable that the subscriber database be 
able to withstand system and component failures to a certain 
extent so that disruption to subscriber services is at a 35 
minimum, if at all. 

SUMMARY OF THE INVENTION 

Accordingly, there is a need for a subscriber database for 
a wireless communications network that is capable of stor- ^ 
ing a large amount of subscriber data, providing fast and 
numerous access of specific subscriber records, and with- 
standing certain failures. 

In accordance with the present invention, a distributed 
redundant database system and methods therefor are pro- 45 
vided which eliminate or substantially reduce the disadvan- 
tages associated with prior systems. 

In one aspect of the invention, a distributed redundant 
database architecture primarily for storing a plurality of 
wireless service subscriber files is provided. The database 50 
architecture includes a first set of processors each having a 
shared memory, where the processors are divided into pro- 
cessor groups. A memory storage device is coupled to each 
processor group in a multi -initiator mode so that each 
memory storage device is accessible by the processors in its 55 
respective processor group. The plurality of subscriber files 
are assigned to the processor groups and further assigned to 
the processors in each processor group to achieve a sub- 
stantially even distribution. The plurality of subscriber files 
are stored in the memory storage devices of respective eo 
assigned processor groups, and are mapped into the respec- 
tive shared memories of the processors. A database manager 
associated with the processors and processor groups is 
provided for managing the distribution and redistribution of 
the subscriber files to the processors. 55 

In another aspect of the invention, a distributed redundant 
database architecture for a wireless communications net- 



156 

2 

work includes first and second service control points, each 
service control point servicing one half of wireless service 
subscribers. The service control points are configured 
similarly, where each service control point includes a first set 
of processors each having a shared memory. The processors 
are divided into processor groups. A pair of mirrored 
memory storage devices is coupled to each processor group 
in a multi-initiator mode. A plurality of subscriber files are 
assigned to the processor groups and further to the proces- 
sors in each processor group to achieve a substantially even 
distribution. The plurality of subscriber files are stored in the 
mirrored memory storage devices of respective assigned 
processor groups, and are further mapped into the respective 
shared memories of the processors. A database manager 
associated with the processors, processor groups, and ser- 
vice control point is provided for managing the distribution 
of the plurality subscriber files to the processors. 

In yet another aspect of the invention, a method for 
organizing data storage and access in a database is provided. 
The data in the database are first organized into a plurality 
of files, each file having a file index associated therewith. 
The plurality of files are assigned to the processor groups 
and further to the processors in each processor group in an 
evenly distributed manner. The assigned files are stored in 
the memory storage device of each processor group accord- 
ing to the assignment, and mapped from the memory storage 
device to a shared memory of each processor. 

A technical advantage of the distributed redundant data- 
base is the capacity to store a large amount of data while still 
be able to search for and access specific data quickly. 
Another advantage stems from the distributed and redundant 
nature of the database architecture — the data stored therein 
is more secure and robust and able to withstand system and 
component failures to a certain extent. 

BRIEF DESCRIPTION OF THE DRAWINGS 
For a better understanding of the present invention, ref- 
erence may be made to the accompanying drawings, in 
which: 

FIG. 1 is a simplified block diagram illustrating the 
relationship between a Service Management System (SMS), 
a Service Control Point (SCP) and its mate SCP, and a base 
station (BS) in wireless communication with subscribers' 
telephone equipment; 

FIG. 2 is a block diagram of a Service Control Point 
(SCP) constructed according to the teachings of the present 
invention; 

FIG. 3 is a more detailed block diagram of the SCP 
according to the teachings of the present invention; 

FIG. 3 A is a more detailed block diagram of file distri- 
bution and redistribution due to 1PU failure according to the 
teachings of the present invention; 

FIG. 4 is an object diagram of a Platform Manager (PM) 
Database Manager; 

FIG. 5 is an object diagram of an Application Processor 
Group (APG) Database Manager; 

FIG. 6 is an object diagram of an Intelligent Processor 
Unit (IPU) Database Manager; 

FIG. 7 is an exemplary flowchart of an APG Database 
Manager initialization process; 

FIG. 8 is an exemplary flowchart of an IPU Database 
Manager initialization process; 

FIG. 9 is an exemplary flowchart of a process in which a 
PM transitions from standby to active operating status; 

FIG. 10 is an exemplary flowchart of a process for 
handling IPU failures; 
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FIG. 11 is an exemplary flowchart of a process for adding with Base Station 18 to support tasks such as portable 

filesystem(s) to an IPU; handset information requests, location queries, location 

FIG. 12 is an exemplary flowchart of a process for registrations, charge rates, and voice mail notification for the 

removing filesystem(s) from an IPU; subscriber using portable handset 20. 

FIG. 13 is an exemplary flowchart of a load balance 5 Some exemplary messages that are transmitted between 

request process; SMS 12, SCPs 14 and 16, and base statioD 18 are shown in 

FIG. 14 is an exemplary flowchart of a load balancing FIG * L When a new subscriber using a portable handset 20 

process; ^ ^ eing added to wireless communications network 10, 

\* • i a L r j t. SMS 12 issues an INSERT command to add a new unique 

FIG. 15 is an exemplary flowchart of a database recon- 1fl , . , . . . . , . 

fi uration rocess- personal subscriber number or telephone number to both 

gura ion process, SCPs 14 and 16. A subscriber who no longer desires wireless 

FIG. 16 is an exemplary flowchart of a shared memory service can be deleted in a similar manner with DELETE 

and disk synchronization process; messages to both SCPs 14 and 16. SMS 12 may also issue 

FIG. 17 is an exemplary flow diagram illustrating the UPDATE messages to provide information, such as add a 

process of synchronizing the databases of mate SCPs; 15 new service, to SCPs 14 and 16. These messages are 

FIG. 18 is an exemplary flowchart of an IPU sync process examples of static data updates, 

used in synchronization of mate SCP databases; and As a portable handset roams, its location may change 

FIG. 19 is an exemplary flowchart of an IPU update fr Qtn lnc coverage area of one base station to another, 

process used in synchronization of mate SCP databases. Updates of base station numbers are provided by the base 

2 station currently covering the portable handset to primary 

DETAILED DESCRIPTION OF THE SCP 16, so that incoming calls to the portable handset can 

INVENTION be routed to that base station. Further, outgoing calls to 

The preferred embodiments) of the present invention is anothcr P ortable handset may begin with a query to primary 

(are) illustrated in FIGS. 1-19, like reference numerals ^ SCP 16 of thc l° cat ion registration of the destination por- 

being used to refer to like and corresponding parts of the table handsct - A database synchronization process is per- 

various drawings formed periodically and/or on demand between SCP 14 and 

FIG. 1 is a high-level block diagram of a distributed 16 t0 u P datc thc ™P**vc copies of the SCPs with this 

redundant database system and architecture 10 operating in ransien a a. 

a portion of a wireless communications network constructed 30 As referred to above, the respective copies of the sub- 
and configured according to the teachings of the present scriber database in SCP 14 and 16 are synchronized on a 
invention. The wireless communications network includes a periodic basis. Database synchronization involves the trans- 
Service Management System (SMS) 12 in communication fer of records or files that have modified or new data to the 
with two mate Service Control Points (SCPs) 14 and 16, male SCR If one SCP faik > its mate scp nas a11 tne data 
which are also in communication with one another. SCPs 14 35 necessary to continue the network operation of subscriber 
and 16 may be coupled to SMS 12 via dedicated point-to- services performed by both SCPs, and all database queries 
point X. 25 links SCPs 14 and 16 are generally physically and u Pf ates of transient data are subsequently routed to the 
located in different cities and may be coupled together via remaining SCP for processing. Details of SCP database 
some communications line such as a point-to-point wide synchronization are set forth below, 
area network (WAN) link or a Media Access Control (MAC) 40 FIG. 2 provides a more detailed block diagram of a SCP 
bridge. SCPs 14 and 16 operate in parallel and provide 16 coupled to its mate SCP 14 constructed according to the 
subscriber database functions for the wireless network by teachings of the present invention. SCP 16 includes an active 
maintaining the subscriber database and additional data- Platform Managers (PM) 34 and a standby Platform Man- 
bases necessary to provide the wireless communications ager 36 coupled by a bus, local area network (LAN), or a 
services. The subscriber database is stored in both SCPs, 45 local area network hub 50 to a predetermined number of 
where one SCP is the primary SCP for half of the Application Processor Groups (APGj-APGJ 38-42. To 
subscribers, and the other SCP is the primary SCP for the provide greater network integrity and fault tolerance, dual 
remaining half of the subscribers. Updates of transient data LAN or hubs may be used to connect the PMs to the APGs 
related to the subscribers, such as current subscriber to provide redundancy. Each APG 38— 42 includes a plurality 
location, are routed to the primary SCP only, but the SCPs 50 of Intelligent Processor Units (lPUj-IPUJ 44-48. One or 
exchange updated transient data on a periodic basis to bring more IPU may be configured as a spare or standby IPU that 
each other's database up to date. Static data updates, such as may be brought on-line as another IPU fails, 
subscriber additions, deletions, and service modifications, Referring to FIG. 3, it may be seen that each Platform 
are initiated by the SMS 12 to both SCPs 14 and 16 Manager 34 and 36 includes a PM Database Manager 
simultaneously. The database configuration of both SCPs are 55 process 52 and an APG Database Manager process 54 for 
preferably exactly alike and the data contained therein each APG. Each IPU^,, 60-64 also has an IPU Database 
nearly identical, so that in the event of one SCP failure, the Manager process 66-70 and shared memory 72-76 residing 
other SCP is capable of taking over the operations of the therein. Shared memory 72-76 may be implemented by any 
entire database load. fast memory device, including random access memory 
Abase station (BS) 18 is in communication with SCP 16, eo (RAM) devices, and is accessible to all the processes resid- 
typically through a Signal Transfer Point (STP) not shown ing in the IPUs. A pair of mirrored memory storage devices 
herein. Base station 18 may serve as a primary base station 80 and 82 are coupled to each IPU 60-64, where IPUs 60-64 
and SCP 16 as a primary SCP for a portable handset 20 may all access the memory storage devices 80 and 82 
belonging to a subscriber. Base Station 18 sends and simultaneously. Simultaneous file access may be accom- 
receives messages to and from personal handset 20 for 65 plished by implementing memory storage devices 80 and 82 
normal call processing functions and to determine user with multi-port media, or by running IPUs 60-64 in , a 
preference information. Service Control Point 16 interacts multi-initiator mode to each memory device 80 and 82, 



06/02/2003, EAST Version: 1.03.0002 



5,890 : 

5 

Memory storage devices 80 and 82 may be implemented 
with solid state disks or any other suitable storage media. In 
the multi-initiator mode, memory storage devices 80 and 82 
may each be coupled to IPUs 60-64 by a separate bus or 
Small Computer Systems Interface (SCSI). Constructed and 5 
configured in this manner, any one of IPUs 60-64 has access 
to both memory storage devices 80 and 82. 

Memory storage devices 80 and 82 may be segmented 
into a predetermined partitions or filesystems, where X of 
them are used to store subscriber files. The portable handset 1Q 
subscriber database is comprised of a fixed number of files 
which are stored on mirrored disks of APGs 38^2 of SCP 
30, where there is a pair of mirrored disks per APG. A subset 
of subscriber records in the entire subscriber database is 
assigned to each subscriber file. Each subscriber file is 
assigned to be stored in a specific filesystem on a specific 15 
pair of mirrored disks in the SCP, such that each APG 
services an exclusive subset of the subscriber database. As 
shown in FIG. 3, the number of files that may be stored on 
a pair of disks is Y. The pair of disks are mirrored, so that 
the contents of the disks, if both are operational, are always 20 
the same. 

To access a particular file on a given pair of disks, the 
filesystem containing that file has to be mounted to a 
directory on an IPU in the APG, where a filesystem can be 
mounted on only one IPU at a time. When a filesystem is 25 
mounted on an IPU, its files are mapped into the shared 
memory of the IPU. During typical operations, each file- 
system is assigned to a particular IPU and is mounted and 
mapped into the shared memory of the IPU so that the data 
contained therein is readily accessible to all the processes 30 
operating in the IPU. Transient data updates containing 
subscriber location information and the like are made only 
to the shared memory of the IPU, but static data updates such 
as subscriber additions, deletions, or service modifications, 
are written immediately out to disk as well as updated in the 35 
shared memory. On an ongoing basis, configurably-sized 
sections of the files mapped to an IPlTs shared memory, 
including transient data updates, are written out to the 
mirrored disks simultaneously to update the copy contained 
therein. The result of this ongoing write operation is to 40 
continuously cycle through the mapped shared memory files 
at a configurable interval so that no excessive input/output or 
CPU peaks are required to update the disk copies. Thus, 
possible intermittent service delays are avoided by the 
continuous writing of small sections of the files to disk. 45 

Referring to FIG. 3A, an exemplary block diagram of file 
distribution and redistribution to the IPUs in an APG is 
shown. If disks 80 and 82 each have six partitions or 
filesystems FS1-FS6, for example, each filesystem may 
have two or three files, F1-F14. In an initial distribution of 50 
the files, IPU, 60 may mount FS1 and map files F1-F3 to its 
shared memory; IPU 2 62 may mount FS2 and map files 
F4-F6 to its shared memory; IPU 3 63 may mount FS3 and 
FS4 and map files F7— F10 to its shared memory; and IPU 4 
64 may mount FS5 and FS6 and map files FU-F14 to its 55 
shared memory. Each IPU may then access only the sub- 
scriber records in the files in the filesystem(s) it has 
mounted. The APG services, as a whole, all the subscribers 
in all the files allocated to it. Subsequently, if IPU 3 63 goes 
down, the files F7-F10 in filesystems FS3 and FS4 are 60 
redistributed to one or more of the remaining IPUs. Id the 
example illustrated in FIG. 3A, the files in FS3 and FS4 are 
redistributed to IPU a 60 and IPU 2 62 so that service to those 
subscribers having information stored in files F7-F10 may 
continue without interruption. Accordingly, the file distribu- 65 
tion is reconfigured as IPUs come into service or go out of 
service. 
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As further examples, a configuration of two APGs, six 
filesystems used per disk in each APG, and 32 subscriber 
files may have an exemplary file assignment shown below: 



APG 


Filesystem 


Subscriber FUe Index 




FS1 


0, 1,2 




FS2 


3, 4, 5 




FS3 


6, 7,8 




FS4 


9, 10, 11 




FS5 


12, 13 




FS6 


14, 15 


2 


FS7 


16, 17, 18 


2 


FSS 


19, 20, 21 


2 


FS9 


22, 23, 24 


2 


FS10 


25, 26, 27 


2 


FS11 


28, 29 


2 


FS12 


30, 31 



It may be seen that the 32 subscriber information files are 
evenly distributed to the APGs with half of the load, or 16 
files, residing on the mirrored disks of each APG. If each 
APG has three active IPUs, then each IPU may be assigned 
two filesystems, which are then mounted and mapped into its 
shared memory. If each APG has four IPUs, then two of the 
IPUs may be assigned two filesystems, and the remaining 
two may be assigned one filesystem each. One or more spare 
IPUs may also be included in each APG that remains in the 
standby mode until an IPU failure is encountered. 

The personal subscriber number (PSN) or call number is 
used to determine the file index of the file storing the 
information related to that account. For example, in the 
above instance where the database is segmented into 32 files, 
a modulo or MOD 32 operation is performed on selected 
digits of the personal subscriber number to yield the sub- 
scriber file index. For most applications, the last four or five 
digits of the personal subscriber number may be used in the 
MOD operation to yield the file index. 

To support 3-4 million subscribers, for example, the 
subscriber information database may be segmented into 128 
files. If five APGs are used to support the system, an 
exemplary file assignment is shown below. 



APG 


Filesysiem 


Subscriber File Index 




FS1 


0, 1,2, 3, 4,5 




FS2 


6, 7, 8, 9, 10, 11 




FS3 


12, 13, 14, 15, 36, 17 




FS4 


IS, 19 




FS5 


20, 21 




FS6 


22, 23 


2 


FS7 


24, 25, 26, 27, 28, 29 


2 


FS8 


' 30, 31, 32, 33, 34, 35 


2 


FS9 


36, 37, 38, 39, 40, 41, 42 


2 


FS10 


43, 44 


2 


FS11 


45, 46 


2 


FS12 


47, 48, 49 


3 


FS13 


50, 51, 52, 53, 54, 55 


3 


FS14 


56, 57, 58, 59, 60, 61 


3 


FS15 


62, 63, 64, 65, 66, 67 


3 


FS16 


68, 69 


3 


FS17 


70, 71, 72 


3 


FS13 


73, 74, 75 


4 


FS19 


76, 77, 78, 79, 80, 81 


4 


FS20 


82, 83, 84, 85, 86, 87 


4 


FS21 


88, 89, 90, 91,92, 93 


4 


FS22 


94, 95 


4 


FS23 


96, 97, 98 


4 


FS24 


99, 100, 101 


5 


FS25 


102, 103, 104, 105, 106, 107 


5 


FS26 


108, 109, 110, 111, 112, 113 


5 


FS27 


114, 115, 116, 117, 118, 119 
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•continued 



APG 


Files ystem 


Subscriber File Index 




5 


FS28 


120, 121 




5 


FS29 


122, 123, 124 


5 


5 


FS30 


125, 126, 127 





In the example above where the database is segmented 
into 128 files, a modulo 128 operation on the last four or five 
digits of the personal subscriber number may be performed 10 
to yield the file index of the file in which subscriber 
information of this call number is located. Therefore, infor- 
mation about a particular subscriber can be located quickly 
in the database. 

It is important to note that the default or initial file 15 
assignment may be modified subsequently depending on 
load and traffic conditions. Each IPU maintains statistics on 
the number of queries it receives and reports the statistics. 
The file assignments may then be redistributed so that any 
IPU is not overworked. Details of load balancing to achieve 20 
a more even distribution is described below. 

Accordingly, PM Database Manager 52 is primarily 
responsible for database load balancing of the IPUs in SCP 
30, and APG Database Manager 54 is primarily responsible 
for the management of the database loads on IPUs in the 25 
respective APG. The IPUs have at least three service states: 
IN_SERVICE, OS_MIN, and OUT_OF_SERVICE. PM 
Database Manager 52, APG Database Manager 54, and IPU 
Database Manager 66-70 may coordinate to unmount file- 
systems from OS_MIN and OUT_OF„SERVICE IPUs 30 
and redistribute the filesystems to the remaining 
IN_SERVICE IPUs. Files may also be moved among 
filesystems to evenly distribute the load carried by each IPU 
and APG. Details on the operating states of the processes are 
discussed in the co-pending U.S. patent application, Ser. No. 35 
08/526,953, tided System and Method for Multi-Site Dis- 
tributed Object Management Environment, pending. 

Referring to FIG. 4, a PM Database Manager 52 may 
include a database configuration table 90 and an IPU table 
92 to handle the database configuration. Database configu- 40 
ration table 90 basically maintains information for each 
filesystem in the entire database, including: 

1. filesystem name 

2. default IPU name 45 

3. current IPU name 

4. APG ID 

5. number of files in the filesystem 

6. a map of the files in the filesystem 

The default IPU is the IPU that the filesystem was initially 50 
assigned to; the current IPU is the IPU that presently 
mounted the filesystem as affected by database reconfigu- 
ration and/or load balancing. IPU table 92 maintains infor- 
mation for each IPU in the system, and may include: 

1. IPU name 55 

2. APG ID 

3. number of files on the IPU currently 

4. number of filesystems on the IPU currently 

A third table, route table 94, is also maintained by PM 60 
Database Manager process 52. Route table 94 contains 
information for each file in the database. It is used to supply 
the routing information to the host, such as a Message 
Transport Network (MTN) (not shown) coupled to the PMs, 
so that the host may direct queries to the appropriate IPU 65 
depending on each IPU's database load. Route table may 
include: 
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1. subscriber file index 

2. name of IPU that file is currently on 

3. IPU ID 

All three tables are persistent and replicated as known in the 
art. All updates and replications of these tables are handled 
by another subsystem not described in detail herein. 

PM Database Manager process 52 includes a number of 
objects to perform the task of managing the database. Ashort 
description follows, but more detailed discussion of the 
function of these objects are set forth below in conjunction 
with references to FIGS. 7-19. As shown in FIG. 4, PM 
Database Handler 96 performs load balancing among the 
IPUs, and for handling solicited requests from the host for 
routing information. Route Table Access 100 and Database 
Config Table Access 102 are objects residing in PM Data- 
base Manager 52 that control access to route table 94 and 
database configuration table 90, respectively. Load Balance 
Handler 104 is an object that contains the processing meth- 
ods for load balancing files and filesystems. Shared Memory 
Array 106 is an array of boolean values in shared memory 
72-76 (FIG. 3) which is used to synchronize load balancing 
and reconfiguration between PM Database Manager 52 and 
APG Database Manager 54. 

FIG. 5 shows a typical composition of APG Database 
Manager 54, which may include APG Database Handler 110 
for providing APG Database Manager 54 an interface to IPU 
Database Manager 66-70 and other processes, and further 
provides methods to be invoked on IPU removes and 
restores. Database Route Control 112 contains various pro- 
cessing methods for reassigning filesystems to handle dif- 
ferent situations of IPU restores, removes, and auditing. It 
also contains information about the APG itself. IPU info 
table 114 is a table that maintains information specific to 
IPUs within the APG, including the current IPU service 
status. Similar to PM Database Manager 52, APG Database 
Manager 54 also includes Database Config Table 90, Data- 
base Config Table Access 116, Route Table Access 116, 
Route Table 94, and Shared Memory Array 120 to control 
access to the data in the respective table. 

Referring to FIG. 6, IPU Database Manager 66 may 
include a number of objects, such as an IPU Database 
Handler 130 which provides an interface to APG Database 
Manager and the application processes on IPU node 60-64 
(FIG. 3). IPU Database Manager 66 is also responsible 
indirectly for mounting and unmounting filesystems on the 
IPU node and mapping and unmapping the database files to 
and from shared memory 72 (FIG. 3). Process 66 Object 130 
also communicates new database load information to the 
application processes on the node. 

A Group File Handler 132 is an object that is responsible 
for periodically synchronizing the database files that are in 
shared memory 72 (FIG. 3) to the mirrored disks 80 and 82 
(FIG. 3). An IPU Disk Manager object 134 is instantiated by 
IPU Database Handler 130 and is responsible for performing 
the mounting and unmounting of the filesystems. A Database 
File Mapper object 136 is responsible for mapping and 
unmapping files to and from shared memory. There is one 
Database File Mapper 136 per file on the IPU node. A 
Subscriber Database Access object 138 is responsible to 
provide processes on remote nodes access to the portion of 
the database handled by this particular IPU. Remote nodes 
include nodes residing on mate SCP 32 (FIG. 2), for 
example. 

The operations of distributed redundant database is 
described in more detail by the flowcharts and block dia- 
gram in FIGS. 7-19, which are discussed in turn below. 
Please also refer to FIGS. 2-6, where necessary, when 
specific structures are discussed. 
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APG Database Manager 52 first instantiates an APG 
Database Manager 54 for each APG in the SCR FIG. 7 is an 
exemplary process flow for APG Database Manager initial- 
ization beginning in block 160. First, an APG Database 
Handler object 110 is instantiated, as shown in block 162. In 5 
block 164, APG Database Handler 110 then instantiates 
Database Route Control 112, Database Config Table Access 
116, and IPU Info Table 114. Database Route Control object 
112 then instantiates and initializes all the tables 90-94 in 
APG Database Manager 52, as shown in blocks 166 and 168. 10 
If the PM is active, as determined in block 170, then an audit 
is performed of IN_SERV1CE lPU(s) by APG Database 
Handler 96 in block 172. The audit yields the database 
load(s) of audited IPU(s), which is used to update the tables 
with this information, as showD in block 174. Subsequently 15 
in blocks 176 and 178, APG Database Manager 54 registers 
itself with the PM node process before ending the initial- 
ization process. The act of registration reveals the object's 
instance to other processes, so that others may communicate 
therewith. 20 

FIG. 8 illustrates an exemplary process flow for IPU 
Database Manager initialization 190. Id block 192, instances 
of IPU Database Handler 130, Group File Handler 132 and 
Subscriber Database Access 138 objects are instantiated. A 
sync timer used for shared memory- to- disk updating is 25 
initiated in block 194. IPU Database Handler 130 then 
requests for its share of the database load from APG Data- 
base Handler 110, as shown in block 196. In response, APG 
Database Manager 54 looks up database configuration and 
IPU tables for information on the filesystems and the 30 
requesting IPU, with this information, IN_SERVICE IPU 
database loads are determined based on the number of IPUs 
that are IN__SERVICE and traffic conditions, as shown in 
blocks 198 and 200. Database loads are distributed to the 
requesting IPU in block 202. IPU Database Manager 66 then 35 
registers itself with the PM node process, as shown in block 
206. IPU Database Manager then receives the load, as 
shown in block 204. Hie filesystem(s) belonging to the 
portion of the database that are assigned to the IPU are then ' 
added or mounted to the IPU, as shown in block 208. The 40 
initialization process subsequently ends in block 210. 

FIG. 9 shows the process flow in the APG Database 
Manager when a Platform Manager 34 transitions from the 
standby mode to the active mode, beginning in block 230. 
All the APG Database Managers 54 operating on the Plat- 45 
form Manager perform an audit of their IPU database loads, 
as shown in block 232. Database Route Controls 112 of each 
APG then initializes all tables, including database config 
table 90, route table 94, and IPU table 92. APG Database 
Handler 110 then obtains a list of IN„SERVICE IPU(S) for 50 
its APG, and queries each IN_SERVICE IPU for its data- 
base load, as shown in blocks 236 and 238. The tables are 
reconstructed and updated with the information supplied by 
the IN_SERVICE IPUs, as shown in block 240. Also 
dependent on this audit information, unassigned 55 
filesystem(s) are assigned to those IN__SERVICE IPU(s) 
that are lightly loaded, and IPU(s) with no load assigned are 
assigned their default database load, as shown in blocks 242 
and 244. The new database load distribution results in new 
routing information in route table 94, which is provided to eo 
the host by APG Database Handlers 110. The standby-to- 
active transition process ends in block 248. 

IPU failures are handled by the process flow shown in 
FIG. 10 beginning in block 250. In block 252, APG Data- 
base Manager 54 receives notification of an IPU failure from 65 
the PM node process. A timer is set for each failed IPU, as 
shown in block 254. If APG Database Manager 54 receives 



an IPU IN__SERVICE notification prior to the timer's 
expiration, as determined in block 256, then nothing more 
needs to be done. However, if no such notification was 
received, and if an IPU exit notification is received or if the 
timer expires, as shown in block 258, the load carried by the 
failed IPU is reassigned and sent to the remaining 
IN_SERVICE IPUs, as shown in blocks 260 and 262. If any 
additional IN_SERVICE IPUs fail now, as determined in 
block 264, execution proceeds to block 260, where the 
database loads are again redistributed to the remaining 
IN_SERVICE IPUs. If no additional IPUs fail, as deter- 
mined in block 264, then Database Route Control 112 
extracts updated routing information from route table 94 and 
APG Database Handler provides this information to the 
host, as sbown in blocks 266 and 268. The process ends in 
block 270. 

To add filesystem(s) to an IPU, the exemplary process 
flow beginning in block 280 and shown in FIG. 11 may be 
used. IPU Disk Manager 134 mounts the filesystem(s) to be 
added to the appropriate IPU, as shown in block 282. The 
files in the mounted filesystem(s) are then mapped to shared 
memory by Group File Handler 132, as shown in block 284. 
Subscriber Database Access 138 then attaches to the shared 
memory files, as shown in block 286. Because records in the 
files are organized and searchable by accessing pointers in a 
Red-Black Tree data structure in the preferred embodiment, 
the Red- Black tree is corrected or rebuilt, if necessary. A 
Red- Black Tree is a balanced tree data structure that facili- 
tates quick searches, where all the records in a file may be 
located by searching the nodes in the Red-Black Tree. Recall 
that the modulo operation yields the file index, and by 
searching the appropriate Red-Black Tree shared memory 
file, the specific record may be accessed. It is important to 
acknowledge that other data structures may be used without 
departing from the spirit of the invention. Thereafter, Sub- 
scriber Database Access 138 sends messages to all con- 
cerned applications about the new IPU file load, as shown in 
block 290, The process then ends in block 292. 

Filesystern removal is also handled by IPU Database 
Handler 130, as shown in block 12 and beginning in block 
300. Subscriber Database Access 138 first detaches files 
from the shared memory, and then detaches applications 
from shared memory, as shown in blocks 302 and 304. 
Group File Handler 132 then deallocates shared memory 
segments, and IPU Disk Manager 134 unmounts the 
filesystems(s) in question, as shown in blocks 306 and 308. 
The filesystern removal process ends in block 310. 

It has been noted above that database loads may be 
balanced among the IPUs in an APG so that an even 
distribution of query traffic is achieved. Further, because 
IPUs may fail or enter into one of the non-operational states 
(OS_MIN or OUT_OF_SERVICE), the database loads 
may need to be reconfigured or redistributed to the remain- 
ing IN_SERVICE IPUs. In order to synchronize load bal- 
ancing and database reconfiguration between PM Database 
Manager 52 and APG Database Managers 54, instances of 
Shared Memory Array 120 are instantiated, one is Reconfig 
Array, an array of booleans in shared memory, and the other 
is Load Balance Flag, a boolean flag also maintained in 
shared memory. If the database in a particular APG is being 
reconfigured due to one or more IPUs going down or 
re-entering service, the appropriate APG Database Manager 
54 sets its corresponding flag in Reconfig Array. Once 
database reconfiguration is completed, APG Database Man- 
ager 54 resets its flag in Reconfig Array. Similarly, while 
load balancing is being performed, the Load Balance Flag is 
set by PM Database Manager 52. 
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FIGS. 13-15 arc flowcharts demonstrating the process to in block 384. The sync timer is then reset, as shown in block 

synchronize load balancing and database reconfiguration. In 386, and execution returns to block 382. At the expiration of 

FIG. 13, an exemplary load balance request process 320 is the sync timer next lime, the next portion of the file is copied 

shown. A load balance may be requested by craft persons to disk. When an entire file has been copied, the oext file is 

through a craft screen interface, by PM Database Manager 5 copied to disk. In this manner, all the files in the shared 

52, or by APG Database Manager 54. The Reconfig Array is memory of each IPU arc copied to disk. Because each IPU 

first checked to sec whether the Reconfig Flag is set for the is assigned a different set of filesystems, the IPUs may 

APG in question, as shown in block 322. If the Reconfig "sync" to disk in parallel in the multi-initiated mode without 

Flag is set, then load balancing is simply aborted in block interfering with each other's operations. It may be noted that 
324 and may be re -attempted at a later time. Because load 10 this "sync" to disk process primarily updates the disks with 

balancing is not a critical operation, it is not required that transient data, such as subscriber current location. Static data 

load balancing waits for reconfiguration to complete, such as adding or deleting Dew subscribers, service option 

although such mechanisms may be instituted. If the Rccon- updates, and subscriber preference data are immediately 

fig Flag for the APG is not set, then the Load Balance Flag written to the mirrored disks generally simultaneously with 
is set, as shown in block 326, and load balancing is 15 writing the same data to the shared memory, 

performed, as shown in block 328. FIG. 17 is a simplified block diagram illustrating the 

Load balancing is shown in exemplary flowchart in FIG, process of synchronizing the databases of two mate SCPs, 

14, beginning in block 340. A request to move one or more SCPi and SCP 2 . Recall that the database configuration of 

specific filesystems to one or more specific IPU is received, both SCPs are identical, so that corresponding IPUs in each 
as shown in block 342. The request is likely to be generated 20 SCP operate on the same files and filesystems. Each SCP has 

by a craft person, or PM or APG Database Manager in view an active PM 400 and 402, in which a PM sync process 404 

of the current load distribution and traffic conditions. In and 406 exchanges the route tabic 94 (FIG. 4) with one 

block 344, Database Route Control 112 makes the necessary another periodically and/or on demand when the table has 

changes to the tables to reflect the balanced load distribution. been updated. The route table obtained from the mate SCP 

The new database loads are provided to both source and 25 is then made available to the respective IPUs 408 and 410 

destination IPUs by PM Database Handler 96, as shown in via a broadcast mechanism. IPUs 408 each includes two 

block 346, If at this time it is detected that the source and/or processes, IPU sync 412 and IPU update 414 for transferring 

destination IPU failed, as shown in block 348, load balanc- modified data to the respective IPUs in mate SCP. Similarly, 

ing is simply terminated in block 354. Otherwise, Database IPUs 410 of SCP 2 also include IPU sync 416 and IPU update 

Route Control 98 extracts the new routing information from 30 418 processes for reciprocating with its own modified data, 

route table 94 and provides it to the host, as shown in blocks Referring to FIG. 18, an exemplary process flow 420 for 

350 and 352. the IPU sync process is shown. In blocks 422 and 424, the 

FIG. 15 shows the process flow for beginning database first block of the file in the shared memory is located. A 

reconfiguration, beginning in block 360. If database recon- determination is made as to whether the end of the file (EOF) 

figuration is desired, the appropriate Reconfig Flag is set for 35 has been reached, as shown in block 426. If the end of the 

the APG, as shown in block 362. Next, a retry counter or file has not been reached, then a dirty bit flag is checked to 

timer (RETRY_CNT) is reset to zero, as shown in block determine whether this record has been modified since the 

364. Execution then enters a loop in which the reconfigu- last synchronization effort, as shown in block 428. The dirty 

ration process waits for load balancing to complete if it is in bit is set to 1 when the data contained in the respective 

progress. The retry counter is first checked to see if it has 40 record is modified. If the dirty bit is not equal to ^indicating 

reached a predetermined upper limit, for example 180, as that the record does not contain any new or modified data, 

shown in block 368. If the upper limit has been reached, it then the next record is located, as shown in block 430. 

is determined that the PM node has failed and its status is However, if the dirty bit is equal to 1, reflecting the fact that 

downgraded to the OS_MIN state. If the retry count has not the record has been modified, then the record is written to a 

yet reached the predetermined upper limit, then the Load 45 buffer, as shown in block 432, and the next record is then 

Balance Flag is checked to see if it is set, as shown in block located and execution returns to block 426. The dirty bit flag 

370. If it is not set, then execution may proceed with of the record is then reset to zero. If in block 426 it is 

database reconfiguration. Otherwise, the retry counter is determined that the end of the file has been reached, then the 

incremented and a predetermined amount of time, for contents in the buffer is transmitted in a message to the IPU 

example one second, is permitted to elapse before returning 50 update of the corresponding IPU in the mate SCP, as shown 

to the beginning of the loop at block 366. in block 434. Next, the next file or the first file if no more 

There are several data synchronization processes taking files remain unprocessed is located, and execution returns to 

place in distributed redundant database 10. The data stored block 424. IPU sync is an endless process that continuously 

in the shared memory of each IPU is synchronized to both transfers the database contents to the male SCP. 

mirrored disks, and all modified data in the database of each 55 The IPU update process is shown in FIG. 19, which 

SCP is provided to its mate SCP. begins in block 440. IPU update receives the a buffer sent by 

FIG. 16 is an exemplary process flow 380 for synchro- IPU sync of the mate SCP, as shown in block 442. The first 

nizing the data in the IPUs' shared memory 72-76 (FIG. 3) record in the buffer is first located, as shown in block 444. 

to mirrored disks 80 and 82 (FIG. 3). In block 382, the IPU The corresponding copy of the record in the IPU is then 

sync timer is checked to determined whether it has expired. 60 updated with the new record, as shown in block 448. If the 

Recall that this timer was initialized during IPU Database current record is not the last record in the buffer, as deter- 

Manager initialization, as shown in block 194 in FIG. 8. If mined in block 448, then the next record in the buffer is 

the sync timer has not yet expired, a predetermined amount located, as shown in block 450, and execution returns to 

of time is permitted to elapse, and the timer is rechecked, block 446 to continue updating the remaining records in the 

until the sync timer is expired. The expiration of the sync 65 buffer. When the last record is reached, as determined in 

timer indicates that it is time to copy a portion or block of block 446, execution returns to block 442 to process the 

a file in the shared memory to the mirrored disks, as shown contents of the next buffer to be received. IPU update is also 
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an endless process that continuously copies the contents of 
buffers received from the mate IPU sync in the mate SCP. 

In this manner, mate SCPs contain nearly identical data 
distributed to the IPUs in an identical manner, so that iD case 
of failure of one SCP, the other SCP is capable of irnmedi- 5 
ately servicing the subscribers of both SCPs. 

Although the present invention and its advantages have 
been described in detail, it should be understood that various 
changes, substitutions and alterations can be made therein 
without departing from the spirit and scope of the invention 10 
as defined by the appended claims. 

What is claimed is: 

1. A distributed redundant database architecture for stor- 
ing a plurality of files, comprising: 

a first set of processors each having a shared memory, said 15 
processors being divided into processor groups, each 
processor of a particular processor group having access 
to the shared memory of each of the other processors 
within the particular processor group; 

a memory storage device coupled to each processor 20 
group, each memory storage device being simulta- 
neously accessible by processors in its respective pro- 
cessor group; 

said plurality of files each having a plurality of records, 
and being assigned to said processor groups and further 25 
to said processors in each processor group to achieve a 
substantially even distribution; 

said plurality of files being stored in said memory storage 
devices of respective assigned processor groups, and ^ 
further being mapped into said respective shared 
memories of said processors; and 

a database manager associated with said processor groups 
for managing the distribution of said plurality files to 
said processors. 35 

2. The distributed redundant database architecture, as set 
forth in claim 1, further comprising: 

a second set of processors being physically remote from 
said first set of processors, and being coupled 
therewith, said second set of processors also being ^ 
grouped into processor groups, each processor group 
being coupled to a memory storage device; 

said plurality of files being assigned to said processor 
groups and further to said processors in each processor 
group to achieve a substantially even distribution in a 45 
similar manner as said first set of processors; 

said plurality of files being stored in said memory storage 
devices of respective assigned processor groups, and 
further being mapped into said respective shared 
memories of said processors in a similar manner as said 50 
first set of processors; and 

a second database manager associated with said processor 
groups for managing the distribution of said plurality of 
files to said second set of processors. 

3. The distributed redundant database architecture, as set 55 
forth in claim 2, wherein said first and second sets of 
processors each actively process database queries and 
updates associated with a different half of records stored in 
said plurality of files, said memory storage devices of both 
sets of processors each storing a copy of said plurality of so 
files. 

4. The distributed redundant database architecture, as set 
forth in claim 3, further comprising first and second database 
synchronization processes associated with said first and 
second sets of processors respectively for transmitting 65 
updated data in respective half of records stored in said 
plurality of files to one another. 



5. The distributed redundant database architecture, as set 
forth in claim 4, wherein said updated data being transmitted 
between said first and second sets of processors are transient 
data. 

6. The distributed redundant database architecture, as set 
forth in claim 4, further comprising: 

a route table recording the file assignment of said plurality 
of files to processors in said first and second sets of 
processors; and 

first and second database sync managers exchanging said 
route tables with one another. 

7. The distributed redundant database architecture, as set 
forth in claim 1, further comprising a database reconfigu- 
ration process executed by said database manager for redis- 
tributing said files to said processors as one or more of said 
processors become inactive and as inactive processors 
become active. 

8. The distributed redundant database architecture, as set 
forth in claim 1, further comprising a load balancing process 
executed by said database manager for moving one or more 
selected files from one • processor to another to evenly 
distribute the amount of processing required to service 
queries and updates to said plurality of files. 

9. The distributed redundant database architecture, as set 
forth in claim 1, further comprising a memory synchroni- 
zation process executed by said database manager for copy- 
ing said plurality of files stored in said shared memories of 
said processors to its respective memory storage devices on 
a periodic basis. 

10. The distributed redundant database architecture, as set 
forth in claim 1, wherein said memory storage device 
includes a redundant memory storage device storing a 
second copy of said files, both said memory storage devices 
being updated simultaneously. 

11. The distributed redundant database architecture, as set 
forth in claim 1, wherein each file includes a plurality of 
records, each record containing information related to a 
subscriber of a wireless service having a personal subscriber 
number, each subscriber record being contained in a file 
having a file index equal to the result of a modulo operation 
on said personal subscriber number. 

12. A distributed redundant database architecture for 
storing a plurality of files, comprising: 

a first set of processors each having a shared memory, said 
processors being divided into processor groups; 

a memory storage device coupled to each processor 
group, each memory storage device being simulta- 
neously accessible by processors in its respective pro- 
cessor group; 

said plurality of files each having a plurality of records, 
and being assigned to said processor groups and further 
to said processors in each processor group to achieve a 
substantially even distribution; 

said plurality of files being stored in said memory storage 
devices of respective assigned processor groups, and 
further being mapped into said respective shared 
memories of said processors; and 

a database manager associated with said processor groups 
for managing the distribution of said plurality files to 
said processors, wherein each file is associated with a 
Red- Black Tree data structure having a plurality of 
nodes corresponding to a plurality of records of the file, 
said nodes of said Red- Black Tree being organized for 
speedy searches to facilitate quick location and access 
of corresponding records in said file. 

13. A distributed redundant database architecture for 
storing a plurality of files, comprising: 
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a first set of processors each having a shared memory, said of a modulo Yoperation on said personal subscriber number, 

processors being divided into processor groups; where Y is the total number of subscriber files. 

a memory storage device coupled to each processor 17. A distributed redundant database architecture for a 

group, each memory storage device being simulta- wireless communications network, comprising: 
neously accessible by processors in its respective pro- s first and second service control points, each service con- 

cessor group- tr °l P° mt servicing one half of wireless service 

said plurality of files each having a plurality of records, subscribers each service control point including: 

and being assigned to said processor groups and furthe a firS ' Set ° f proc T° T , ^ * *" ed 

. , & & . , * . said processors being divided into processor croups, 

to said processors in each processor group to achieve a cach proccssor of a parucular pressor group hav- 

substantially even distribution; «> mg access (0 (he shared memory of eacfa of 

said plurality of files bemg stored in said memory storage processors within the particular processor group, 

devices of respective assigned processor groups, and said processors of said processor groups being 

further being mapped into said respective shared assigned subscriber files having records containing 

memories of said processors; and subscriber information, said files being substantially 

a database manager associated with said processor groups 15 evenly distributed among said processors in cach 

for managing the distribution of said plurality files to processor group; 

said processors, wherein said memory storage devices a P air of mirrored memory storage devices coupled to 

are multi-port disks eac ^ P rocessor g rou P> eac h pair of mirrored memory 

14. A distributed redundant database architecture for 2Q stora S e device bein £ accessible by its respective 

storing a plurality of files, comprising: ?J° Ce t r ° U ?i' u • j ■ 

c c - * . , . said subsenber files being stored m said pairs of 

a first set of processors each having a shared memory, said mirrored mcmory storagc dcviccs of ctivc 

processors being divided into processor groups; assigned processor groups, and further being mapped 

a memory storage device coupled to each processor into said respective shared memories of said proces- 

group, each memory storage device being simulta- 25 sors ; ana " 

neously accessible by processors in its respective pro- a database manager associated with said processor 

cessor group; groups for managing the distribution of said files to 

said plurality of files each having a plurality of records, sa * d processors. 

and being assigned to said processor groups and further r 18 ' . The distnbuted redundant database architecture, as set 

to said processors in each processor group to achieve a 30 forth lD claim 17 > &rther comprising: 

substantially even distribution; a rou f e ^ bl& recordi ng the file assignment of said sub- 

•j i v* <?<ii u ■ j* j scriber files to processors in said first and second 

devicTs of res STa^ 2 m * ""^ C ° ntr01 P ° inlS; and 

evices o respective assigned processor groups, and £ fSl and database sync processes in respective 

further being mapped into said respective shared ... u ■ -a * . 1.1 ,i_ 

f & . , rr - , c service control points exchanging said route tables with 

memories of said processors; and 35 onc 

a database manager associated with said processor groups 19. The distributed redundant database architecture, as set 

for managing the distribution of said plurality files to forth in claim 17, further comprising a database reconfigu- 

said processors, wherein said memory storage devices ration process executed by said database manager for redis- 

are coupled in a multi-initiator mode with said proces- tributing said subscriber files to said processors as one or 

sor group. 40 more of said processors become inactive or one or more 

15. A distributed redundant database architecture for inactive processors become active. 

storing a plurality of files, comprising: 20. The distributed redundant database architecture, as set 

a first set of processors each having a shared memory, said forth in claim V 7 ' further com Prising a load balancing 

processors being divided into processor groups; P rocess exe cuted by said database manager for moving one 

, . , , , 45 or more selected subscriber files from one processor to 

a memory storage device coupled to each processor another t0 evenly djstribute the am0U[U J ssi 

group, each memory storage device being simulta- requ ired to service queries and updates to said plurality of 

neously accessible by processors in its respective pro- subscriber files 

cessor group; 21. The distributed redundant database architecture, as set 
said plurality of files each having a plurality of records, 50 forth in claim 17, further comprising a memory synchroni- 
and being assigned to said processor groups and further za tion process executed by said database manager for copy- 
to said processors in each processor group to achieve a ing said plurality of subscriber files stored in said shared 
substantially even distribution; memories of said processors to its respective pairs mirrored 
said plurality of files being stored in said memory storage memory storage devices on a periodic basis. 

devices of respective assigned processor groups, and 55 22. The distributed redundant database architecture, as set 

further being mapped into said respective shared forth in claim 17, wherein each subscriber file includes a 

memories of said processors; and plurality of records, each record containing information 

a database manager associated with said processor groups related to a wireless service subscriber having a personal 

for managing the distribution of said plurality files to subscriber number, said record of said subscriber being 

said processors, wherein said memory storage device is 60 stored in a subscriber file having a file index equal to the 

partitioned into X filesystems, said files being generally result of a modulo operation on said personal subscriber 

evenly distributed among said filesystems. number. 

16. The distributed redundant database architecture, asset 23. A distributed redundant database architecture for a 
forth in claim IS, wherein each file includes a plurality of wireless communications network, comprising: 

records, each record containing information related to a 65 first and second service control points, each service con- 
subscriber of a wireless service having a personal subscriber trol point servicing one half of wireless service 
number, said file having a file index being equal to the result subscribers, each service control point including: 
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a first set of processors each having a shared memory, 
said processors being divided into processor groups, 
said processors of said processor groups being 
assigned subscriber files having records containing 
subscriber information, said files being substantially 
evenly distributed among said processors in each 
processor group; 

a pair of mirrored memory storage devices coupled to 
each processor group, each pair of mirrored memory 
storage device being accessible by its respective 
processor group; 

said subscriber files being stored in said pairs of 
mirrored memory storage devices of respective 
assigned processor groups, and further being mapped 
into said respective shared memories of said proces- 
sors; and 

a database manager associated with said processor 
groups for managing the distribution of said files to 
said processors; and 
first and second database synchronization processes asso- 
ciated with said first and second service control points 
respectively for transmitting updated transient data, 
such as subscriber location, in said subscriber files to 
one another. 

24. A distributed redundant database architecture for a 
wireless communications network, comprising: 

first and second service control points, each service con- 
trol point servicing one half of wireless service 
subscribers, each service control point including: 
a first set of processors each having a shared memory, 
said processors being divided into processor groups, 
said processors of said processor groups being 
assigned subscriber files having records containing 
subscriber information, said files being substantially 
evenly distributed among said processors in each 
processor group; 
a pair of mirrored memory storage devices coupled to 
each processor group, each pair of mirrored memory 
storage device being accessible by its respective 
processor group; 
said subscriber files being stored in said pairs of 
mirrored memory storage devices of respective 
assigned processor groups, and further being mapped 
into said respective shared memories of said proces- 
sors; and 

a database manager associated with said processor 
groups for managing the distribution of said files to 
said processors, wherein each subscriber file is asso- 
ciated with a Red-Black Tree data structure having a 
plurality of nodes corresponding to a plurality of 
records of the subscriber file, said nodes of said 
Red-Black Tree being organized for speedy searches 
to facilitate quick location and access of correspond- 
ing records in said subscriber file. 

25. A distributed redundant database architecture for a 
wireless communications network, comprising: 

first and second service control points, each service con- 
trol point servicing one half of wireless service 
subscribers, each service control point including: 
a first set of processors each having a shared memory, 
said processors being divided into processor groups, i 
said processors of said processor groups being 
assigned subscriber files having records containing 
subscriber information, said files being substantially 
evenly distributed among said processors in each 
processor group; i 
a pair of mirrored memory storage devices coupled to 
each processor group, each pair of mirrored memory 



storage device being accessible by its respective 
processor group; 
said subscriber files being stored in said pairs of 
mirrored memory storage devices of respective 
5 assigned processor groups, and further being mapped 

into said respective shared memories of said proces- 
sors; and 

a database manager associated with said processor 
groups for managing the distribution of said files to 
io said processors, wherein said mirrored memory stor- 

age devices are multi-port disks. 

26. A distributed redundant database architecture for a 
wireless communications network, comprising: 

first and second service control points, each service con- 
15 trol point servicing one half of wireless service 
subscribers, each service control point including: 
a first set of processors each having a shared memory, 
said processors being divided into processor groups, 
said processors of said processor groups being 
20 assigned subscriber files having records containing 

subscriber information, said files being substantially 
evenly distributed among said processors in each 
processor group; 
a pair of mirrored memory storage devices coupled to 
25 each processor group, each pair of mirrored memory 

storage device being accessible by its respective 
processor group; 
said subscriber files being stored in said pairs of 
mirrored memory storage devices of respective 
30 assigned processor groups, and further being mapped 

into said respective shared memories of said proces- 
sors; and 

a database manager associated with said processor 
groups for managing the distribution of said files to 
35 said processors, wherein said mirrored memory stor- 

age devices are coupled to said processors in each 
processor group in a multi-initiator mode. 

27. A distributed redundant database architecture for a 
wireless communications network, comprising: 

40 first and second service control points, each service con- 
trol point servicing one half of wireless service 
subscribers, each service control point including: 
a first set of processors each having a shared memory, 
said processors being divided into processor groups, 
45 said processors of said processor groups being 

assigned subscriber files having records containing 
subscriber information, said files being substantially 
evenly distributed among said processors in each 
processor group; 
>o a pair of mirrored memory storage devices coupled to 
each processor group, each pair of mirrored memory 
storage device being accessible by its respective 
processor group; 
said subscriber files being stored in said pairs of 
>5 mirrored memory storage devices of respective 

assigned processor groups, and further being mapped 
into said respective shared memories of said proces- 
sors; and 

a database manager associated with said processor 
so groups for managing the distribution of said files to 

said processors, wherein said mirrored memory stor- 
age devices are each partitioned into X filesyslems, 
said files being generally evenly distributed among 
said filesystems. 
>5 28. The distributed redundant database architecture, as set 
forth in claim 27, further comprising a database reconfigu- 
ration process for redistributing said filesystems among said 
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processors in a processor group in the event one or more 
processors in said processor group becomes inactive or one 
or more inactive processors become active. 

29. The distributed redundant database architecture, as set 
forth in claim 27, wherein each file includes a plurality of 5 
records, each record containing information related to a 
subscriber of a wireless service having a personal subscriber 
number, said file having a file index being equal to the result 
of a modulo Y operation on said personal subscriber number, 
where Y is the total number of subscriber files. 10 

30. A method for organizing data storage and access in a 
database, comprising the steps of: 

organizing data in said database into a plurality of files, 
each file having a file index and contain a plurality of 
records; 15 

providing a first set of processors and dividing said 
processors into processor groups, each processor group 
coupled to a memory storage device, each processor 
within a particular processor group having a shared 
memory that is accessible by every other processor 20 
within the particular processor group; 

assigning said plurality of files to said processor groups 
and further to said processors in each processor group 
in an evenly distributed manner; and 

storing said assigned files in said memory storage device 
of each processor group according to said assignment, 
and mapping said files assigned to each processor from 
said memory storage device to the shared memory of 
each processor. 30 

31. The method, as set forth in claim 30, further com- 
prising the steps of: 

receiving database queries with reference to specific files; 
consulting a route table for file assignment to processors; 
and 

routing said received database queries to processors 
assigned to said specific files. 

32. The method, as set forth in claim 30, further com- 
prising the steps of: 

receiving data updates with reference to specific files; 
consulting a route table for file assignment to processors; 
and 

updating data stored in said shared memory of said 
processors assigned to said specific files. 45 

33. The method, as set forth in claim 32, further com- 
prising the steps of updating data stored in said memory 
storage device with data stored in said shared memories of 
each processor in said respective processor group. 

34. The method, as set forth in claim 30, further com- 50 
prising the steps of: 

receiving data updates with reference to specific files; 
consulting a route table for file assignment to processors; 
and 

updating data stored in said shared memory of said 
processors assigned to said specific files and said 
respective memory storage device of the processor 
group. 

35. The method, as set forth in claim 30, further com- g0 
prising the step of auditing said processors to determine file 
assignments thereto. 

36. The method, as set forth in claim 30, further com- 
prising the steps of: 

detecting one or more processors going inactive; and 65 
reconfiguring the distribution of files to remaining active 
processors. 
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37. The method, as set forth in claim 30, further com- 
prising the steps of: 

monitoring data access and update traffic being processed 

by each processor; and 
moving one or more files among said processors to 

balance the traffic load on the processors. 

38. The method, as set forth in claim 30, further com- 
prising the steps of: 

providing a backup memory storage device as a mirror 
device for each memory storage device; and 

performing all data updates to both memory storage 
devices. 

39. The method, as set forth in claim 30, further com- 
prising the steps of: 

providing a second set of processors and dividing said 
processors into processor groups, each processor group 
coupled to a memory storage device; 

assigning said plurality of files to said processor groups 
and further to said processors in each processor group 
in an evenly distributed manner as in said first set of 
processors; and 

storing said assigned files in said memory storage device 
of each processor group according to said assignment, 
and mapping said files assigned to each processor from 
said memory storage device to a shared memory of 
each processor. 

40. The method, as set forth in claim 30, further com- 
prising the steps of synchronizing the data stored in shared 
memories of said first and second sets of processors. 

41. The method, as set forth in claim 40, wherein the data 
synchronizing step further comprises the steps of exchang- 
ing data updates to said files. 

42. The method, as set forth in claim 30, further com- 
prising the steps of: 

detecting one or more processors going inactive; 
reconfiguring the distribution of files to remaining active 
processors; 

monitoring data access and update traffic being processed 

by each processor; 
moving one or more files among said processors to 

balance the traffic load on the processors; and 
coordinating said reconfiguration and file moving steps. 

43. The method, as set forth in claim 30, further com- 
prising the steps of: 

detecting one or more inactive processors becoming 
active; and 

reconfiguring the distribution of files to said newly active 
processors. 

44. A method for organizing data storage and access in a 
database, comprising the steps of: 

organizing data in said database into a plurality of files, 
each file having a file index and contain a plurality of 
records; 

providing a first set of processors and dividing said 
processors into processor groups, each processor group 
coupled to a memory storage device; 

assigning said plurality of files to said processor groups 
and further to said processors in each processor group 
in an evenly distributed manner, and 

storing said assigned files in said memory storage device 
of each processor group according to said assignment, 
and mapping said files assigned to each processor from 
said memory storage device to a shared memory of 
each processor; 
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receiving data updates with reference to specific files; 
consulting a route table for file assignment to processors; 
and 

updating data stored in said shared memory of said 

processors assigned to said specific files; 
updating data stored in said memory storage device with 

data stored in said shared memories of each processor 

in said respective processor group, wherein said data 

updating step includes the steps of: 

initializing a synchronization timer; 

copying at least a portion of a file at the expiration of 
said synchronization timer to said memory storage 
device; and 

resetting said synchronization timer and repeating said 
copying and timer resetting steps to copy all files. 

45. A method for organizing data storage and access in a 
database, comprising the steps of: 

organizing data in said database into a plurality of files, 
each file having a file index and contain a plurality of 2 o 
records; 

providing a first set of processors and dividing said 

processors into processor groups, each processor group 

coupled to a memory storage device; 
assigning said plurality of files to said processor groups 25 

and further to said processors in each processor group 

in an evenly distributed manner; 
storing said assigned files in said memory storage device 

of each processor group according to said assignment, 

and mapping said files assigned to each processor from 

said memory storage device to a shared memory of 

each processor; 
synchronizing the data stored in shared memories of said 

first and second sets of processors; 
marking each record containing modified data as dirty as 

the data is being modified, said files having a plurality 

of records; 

transferring a copy of all dirty record of all the files to a 
buffer; and 

transmitting the buffer to said second set of processors. 

46. The method, as set forth in claim 45, wherein said 
transferring step includes the step of transferring records of 
files serviced by each processor individually, and said trans- 
mitting step includes the step of transmitting said buffer to 
a corresponding processor in said second set of processors. 

47. A method for organizing data storage and access in a 
database, comprising the steps of: 
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organizing data in said database into a plurality of files, 
each file having a file index and contain a plurality of 
records; 

providing a first set of processors and dividing said 
processors into processor groups, each processor group 
coupled to a memory storage device; 

assigning said plurality of files to said processor groups 
and further to said processors in each processor group 
in an evenly distributed manner, and 

storing said assigned files in said memory storage device 
of each processor group according to said assignment, 
and mapping said files assigned to each processor from 
said memory storage device to a shared memory of 
each processor; 

associating a file index with each file; 

storing information on a wireless service subscriber in a 
record in one of said files; 

associating a personal subscriber number with said wire- 
less service subscriber; and 

performing a modulo operation on said personal sub- 
scriber number to compute for said file index thereof. 

48. A method for organizing data storage and access in a 
database, comprising the steps of: 

organizing data in said database into a plurality of files, 
each file having a file index and contain a plurality of 
records; 

providing a first set of processors and dividing said 
processors into processor groups, each processor group 
coupled to a memory storage device; 

assigning said plurality of files to said processor groups 
and further to said processors in each processor group 
in an evenly distributed manner; and 

storing said assigned files in said memory storage device 
of each processor group according to said assignment, 
and mapping said files assigned to each processor from 
said memory storage device to a shared memory of 
each processor; 

associating each record of a file with a node in a Red- 
Black Tree data structure; and 

searching among nodes of said Red-Black Tree data 
structure to locate a specific record. 

49. The method, as set forth in claim 48, wherein said 
associating step comprises the step of defining a pointer in 
each node for pointing at respective records. 
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